The design, testing and fabrication of semiconductor circuits, such as microprocessors and microcontrollers, is often an expensive and time-consuming process. Several types of computer aided design (CAD) tools have been developed or proposed to facilitate the design and fabrication of integrated circuits. Typically, computer aided design techniques initially encode the specifications of a desired integrated circuit using a hardware description language, such as the (VHSIC (Very High Speed Integrated Circuits) Hardware Description Language) (VHDL) from the Institute of Electrical and Electronics Engineers (IEEE) of New York, N.Y. or Verilog, commercially available from Cadence Design Systems, Inc. of Santa Clara, Calif. Generally, such high definition language specifications define an integrated circuit in terms of desired functionality and desired inputs and outputs. The high definition language specifications are utilized and revised throughout the design and debugging process to minimize hardware faults, and are ultimately utilized to fabricate the final silicon product.
Likewise, the software programs associated with semiconductor circuits, such as microprocessors and microcontrollers, must be similarly tested and debugged to ensure that software faults do not interfere with the operation of the semiconductor circuit. In addition, each change to an existing software program must be tested to ensure that the change does not affect the operation of the original code. In view of the high development costs associated with the semiconductor manufacturing process, it is imperative that software faults are detected and corrected early in the development cycle. Due to the high costs of fabricating special versions of a semiconductor circuit that are needed for internal access to the device, software debugging devices are costly and typically lag production of the final silicon product by a number of years. Thus, conventional testing and debugging techniques for such software programs are typically performed on simulated or emulated hardware renderings of the actual silicon device.
FIG. 1A shows a conventional development environment for testing software programs associated with a semiconductor circuit. The program to be tested is initially loaded onto a computing device 50, such as a workstation, connected to an emulator 60 and a bondout device 70. The bondout device 70 is a special version of the actual integrated circuit being designed, where additional connections are made (bonded out) to internal circuits of the device to give access and control of the device from external circuitry (not shown). The computing device 50 controls the predetermined testing of the system. The emulator 60 includes capture and control logic which monitors the contents of the program address register and the internal data bus and various control lines of the bondout device 70 and provides the captured data to the computing device 50 for analysis. The bondout device 70 is typically physically connected to the device with which the microcontroller will ultimately interface. For a more detailed discussion of a conventional development environment for testing software programs associated with a semiconductor circuit, see U.S. Pat. No. 4,674,089, incorporated by reference herein.
A unique bondout device 70 is required for each type of microprocessor that is developed. Furthermore, if the speed of operation of the microprocessor is changed or the size of the memory is modified during the development process, a new bondout device 70 is required. Thus, software for a particular microprocessor cannot be fully tested using conventional techniques until an accurate and up-to-date bondout device 70 representation of the microcontroller is available. The hardware external to the bondout device 70 rapidly becomes very complex as additional debugging features are added. Thus, a significant amount of hardware must be plugged into a target board, with resultant mechanical and electrical unreliability. The bondout device 70 itself introduces problems since it is a low volume device (one per emulator). By definition, the bondout device 70 is a more complex derivative of the volume silicon and its availability significantly lags production of the final silicon product. Any errors or undesired characteristics of this low volume part are expensive to diagnose and eradicate, typically requiring production of a new device.
When software programs are delivered to a customer, the probability that the customer will find a bug in the program is directly related to the percentage of the code that was executed during testing, often referred to as "code coverage." For example, testing of a scientific calculator program by adding "two" plus "two" ("2 +2") will not evaluate the accuracy of the floating point or trigonometric capabilities of the scientific calculator program. However, if every possibility was tested exhaustively, the customer will never find a bug. Of course, to perform a test that multiplies every possible number by every other possible number and checks the result is not a practical solution.
Generally, the test suite designed to challenge a given program should exercise as much of the program code as possible. Ideally, every byte of program code should be run, and the result checked. Furthermore, the extent of the code tested, relative to the overall code size, should be determined and reported.
Existing code coverage instrumentation techniques have a number of drawbacks, which if overcome, could extend the utility of software testing tools and the accuracy of the underlying programs tested by such tools. Specifically, existing coverage instrumentation tools typically link the program being tested to a special coverage library, thereby increasing code size, preventing execution in real-time and not testing the actual code shipped. In effect, the test results are obtained from a program that is larger, slower and potentially exhibits different behavior than the program that will be released to customers. In addition, most existing coverage instrumentation tools operate by evaluating the source code, and cannot give test results that include coverage of the library files associated with the source code, such as C Standard Libraries (for which source code is generally not available). Finally, most existing coverage instrumentation tools are poorly integrated with the source code, and issue only partial diagrams illustrating unexecuted paths, rather than directly relating the results to the source code.
In addition to the importance of diligent testing of the software, it is often equally important to record information about the tests performed, as well as the test results, for documentation, verification and authentication purposes. Historically, the disparate and often incompatible software testing and debugging systems often made it difficult to integrate the test information into a standard documentation, verification and authentication environment. In addition, conventional software testing and debugging systems are typically stand-alone units tailored to a particular application. Thus, the lack of a standard interface prevents a user from controlling the testing and debugging processes from another application program.
As apparent from the above-described deficiencies with conventional systems for testing and debugging software for microcontrollers, a need exists for a low cost system for testing and debugging software by a programmer at compile time. A further need exists for a testing and debugging system that accurately reports the amount of time it took to execute the software program, taking into account hardware configurations and peripheral devices, to allow tuning of algorithms. Yet another need exists for a software testing and debugging system that facilitates unlimited breakpoints on any condition. Another need exists for a code coverage instrumentation tool that operates at the machine code level, does not change the program being tested, and is integrated with debugging tools to lead the user directly to relevant unexecuted source code. A further need exists for a testing and debugging system that provides a standard interface to general-purpose software applications, to permit the general-purpose applications to load, run and interrogate the software testing and debugging tool and record results in a standard document.